1.2. Selecting a Load Balancer Type
To lower cost and
complexity, you should select a single load-balancing solution that
works for each type of traffic. A large number of load-balancing
options are available on the market; it is important to make an
informed choice. Consider the following criteria during the
decision-making process:
Features Does the load balancer have features such as SSL offloading that you will use now and in the future?
Manageability How easy is the solution to configure and maintain?
Failover detection Does the solution support advanced detection (service awareness) or simple ping (host awareness)?
Affinity What options does the solution support to keep client connections returning to the same host?
Cost How much will it cost to implement the solution?
Scale How does the solution work as the number of hosts increases?
Load balancers can be
categorized into four distinct categories: Software Load Balancers,
Hardware Load Balancers, Intelligent Firewalls, and Round Robin DNS.
The following sections discuss each of these categories.
1.2.1. Software Load Balancing
Windows Network
Load Balancing (NLB) has been part of the Windows Server operating
system since Windows NT 4.0. Of course, a lot has changed since its
early days. NLB can scale to 32 hosts on Windows Server 2008 R2, but
the practical limit for Exchange is 8 hosts based on documentation
provided about Microsoft's internal deployment experience. One
advantage of NLB is that it is relatively inexpensive to implement.
One disadvantage of NLB is that
you cannot use it combined with Windows Clustering. If you are trying
to configure an all-in-one server that has the Mailbox role and Client
Access Server role, and you are using DAGs, you must use a non-Windows network
load-balancing solution for client access. Another drawback is that NLB
only supports source IP affinity or no affinity. This may limit its
ability to effectively load balance across all of the Client Access
protocols. NLB also has no built-in intelligence to test server health
or functionality before sending traffic to a host. If the IIS service
has stopped on one Client
Access server, NLB will continue to send traffic to that node, unless
it is reconfigured to stop. This can be partially overcome when NLB is
deployed along with Microsoft System Center Operations Manager 2007 R2
and the NLB Management Pack, which may be an option for people that
already use Operations Manager.
Other software-based load balancers are installed on a separate server or other hardware. These solutions are often more similar to hardware load balancers or application firewalls than the functionality of NLB.
1.2.2. Hardware Load Balancers
If you need to support
more than eight nodes in your Active Directory site, you must consider
a hardware load balancer. Having a dedicated piece of specialized
hardware allows for the best performance and a considerable number of
features. Most hardware
load balancers support multiple affinity types, and even allow for the
ability to fall back if one type fails. Typically, hardware load
balancers support more advanced node health checks. These range from
simple ping tests to measuring response times to custom Web pages. More
expensive solutions also provide hardware redundancy, further
eliminating any single points of failure.
Probably the biggest
disadvantage is the cost of deploying a hardware solution. However, for
large-scale deployments, this is typically the solution selected.
1.2.3. Application Firewalls
Application (Intelligent) firewalls, such as Microsoft Threat Management Gateway (TMG) or Forefront
Unified Access Gateway (UAG), are similar to the hardware load balancer
solution, but can also provide additional security features. For
example, with Active Directory Domain Services (AD DS) security groups,
you can control what time of the day groups of users can access OWA.
One disadvantage is that
with this great power comes great complexity. These solutions require
more testing and more administration and operational support compared
to the other solutions. Another disadvantage is that these do not
perform RPC load balancing; in order to do this another solution is also required.
1.2.4. DNS Round Robin
DNS
round robin uses DNS's ability to map multiple hosts to a common name.
For example, if you have three Client Access servers the DNS A record
entries would look like this:
mail.litwareinc.com 192.168.1.2
mail.litwareinc.com 192.168.1.3
mail.litwareinc.com 192.168.1.4
The first client to request mail.litwareinc.com
would have the IP address of 192.168.1.2 returned. The second request
would have 192.168.1.3 returned, and the third request would have
192.168.1.4 returned. The fourth request would have the first IP
address returned again, and the pattern would continue. The main
advantage of this is that it has very little or no cost to implement
and it's very easy to configure.
Unfortunately, the limitations of DNS
round robin limit its use to lab environments and very small
implementations. These limitations include no support for affinity,
which requires the application to maintain affinity. For example, a Web
browser navigating to webmail.contoso.com
will actually use the IP address the DNS server returns from the name
resolution query. Internet Explorer will have this DNS entry cached for
about 30 minutes. If the server became unavailable during that cache
period, the Web browser could not be automatically redirected to the
new server. Because of this caching, the Web browser will attempt to
reach an unavailable server until its cache expires. DNS
round robin also does not have any health checks or dead node removal.
In the preceding example, if 192.168.1.3 becomes unavailable, DNS will
continue to return the down host's IP address every third request
unless it is manually reconfigured. Another problem is that if multiple
clients share the same local DNS server as in a LAN environment, all of
those clients will use the same IP address that is cached by the local
DNS server; if most of the clients are from the same location, the load
will be very balanced across the servers. Finally, changes to DNS can
take time to propagate. If a new Client Access server is added to DNS, it will be underutilized until the record propagates fully.
